Network security protocols are used to ensure privacy and integrity of communication on an open public network. These protocols are typically intended to achieve end-to-end security guarantees such that the communication is private to the entities who establish the parameters of the secure communication channel.
FIG. 1 shows an example of a typical secure communication between a client 10 and a server 11. The client and the server establish such a secure connection 12 by first establishing the parameters of the connection through a handshake. Here, the client and server can use any of a variety of protocols for communication. Typically the client establishes a connection with the server through the transport protocol. Then they jointly establish the parameters of the secure connection by negotiating the cryptographic material, if any, to be used to encrypt the packets of the communication. Typically during this negotiation phase the peers in the communication authenticate themselves using one of several cryptographic mechanisms. After this negotiation phase, when the client or the server receives a packet, it identifies the peer of the secure connection using the mechanisms of the transport protocol such as socket number, port number etc. This enables the client to identify the secure communication parameters to be used to decrypt or verify the data on the channel used. Without possession of the cryptographic and other parameters of this secured communication channel, no entity can eavesdrop on the contents of the packets. Thus only the client and server can decrypt data sent on this channel. This is a normal trust model for communication between a client and server.
In several applications such as web-browsing, the client and the server wishing to establish a secure connection, do so through a proxy. There are several reasons for this split communication. The proxy is able to log communications initiated by the client. An example is the case of a proxy implementing the SOCKS protocol. Since the network security protocol generally ensures that the communication is private to the client and the server, the proxy functions only as a gateway. It does not see unencrypted information flowing through it, and only relays packets to and from the client to the server.
FIG. 2 shows another client-server usage scenario where the client 10 shown talks to a remote server 11 through a proxy 20. Typical examples of such a scenario are the cases where the proxy implements the SOCKS protocol or is a HTTP proxy. In these scenarios, the proxy is used for several reasons. These include logging the communications initiated by the client (in the case of the SOCKS protocol) or using a caching mechanism wherein the proxy stores commonly requested information (in the case of the HTTP proxy).
In the situation shown in FIG. 2, the dashed lines 23 indicate that when the client ID establishes a secure connection with the server 11, this connection is tunneled through the proxy 20 such that the packets that flow as part of the communication protocol are opaque to the proxy 20. This is achieved, for instance, by encryption of the data flowing between the client and the server. The proxy 20 can not undo the encryptions and any other cryptographic mechanisms used in the secure connection since it does not possess the cryptographic material negotiated between client 10 and server 11 using cryptographic means. In this instance, the protocol 21 that client 10 uses to communicate with the proxy 20 is the same as the protocol 22 that the proxy uses to communicate with server 11. The packets in the protocol are relayed by the proxy 20 without any intervention.
In some application scenarios, where computationally limited clients wish to connect over wireless or other links, the proxy may provide the following additional functionalities:                (a) If the client does not support the same communication protocols as the server, the proxy acts as a converter between the protocols the client supports and those that the server understands. For example, the client may have the protocols specified by the Wireless Applications Protocol (WAP), whereas the server may support only the protocols of the Internet Protocol (IP)        (b) The proxy adapts the content supplied by the server to fit the constraints of the communication links and the computational, functional and graphical constraints of the client.        
FIG. 3 shows an example of an application scenario where the client 10 does not support the same communication protocols as the server 11. Thus, for a communication link to be established the client communicates to a proxy 20 using a set of protocols 30 which both the client and proxy support. The proxy 20 then communicates to the server 11 using a different set of protocols 31 which the server 11 supports. If the client 10 wishes to establish a secure connection to the server 11, it can only do so by establishing a secure connection to the proxy which then establishes a second connection to the server. It is important to note that in such scenarios, the trust model of FIG. 1 does not hold. This is because the proxy 20 has to translate protocol 30 to protocol 31 and vice versa, and is thus able to see all the messages that flow between the client and the server. The scenario depicted in FIG. 3 occurs, for instance, if the client only supports the protocols specified by the Wireless Applications Protocol (WAP), whereas the server only supports those of the Internet Protocol (IP). A typical client is a pervasive computing device. In this example, due to the considerable differences in the protocols on either side, the proxy has to decrypt the data exchanged by the client and the server in order to forward it to the other side of the connections.
These requirements of protocol conversion and content adaptation are orthogonal to the end to end security requirements which are: to prevent exposure and modification of content by a third party. It is therefore advantageous to have a system to provide the original end to end security guarantees without modifying the server at the back end. In this way secure communication is possible even without forcing the client and server to support a common set of protocols.